개짱짱 클러스터화

기존 문제점 부가적인 목표 고려사항 계획 Plan A(Default)Plan B(Second-best)계획 실행 및 발생한 문제 결과 및 회고

지금까지 인포팀은 클라우드 서버로 AWS Lightsail 인스턴스를 쓰고 있었습니다. 그러나 인포팀 서비스가 늘어나면서 서버에 과부하가 생겨, 서버를 증설하게 되었습니다.

기존 문제점

Lightsail은 비용이 저렴한 대신 CPU 크레딧이란 제도를 가집니다. CPU 성능 베이스라인이 20%로 정해져 있는데, 이 CPU 사용량을 넘어가면 CPU 크레딧이 차감됩니다. 크레딧을 다 쓰게 되면 스로틀링이 걸려 성능이 대폭 감소하고, ssh조차 접속할 수 없게 됩니다.

따라서 CPU 사용량 제한을 늘리고 성능도 높이기 위해 Lightsail large plan에서 xlarge plan으로 클러스터 확장을 결정했습니다.

부가적인 목표

이번 증설은 단순한 확장이 아닌, 서버 최적화 및 인프라 유지보수 향상 또한 진행하고자 하였습니다.

Ubuntu 업데이트: 22.04 → 26.04

control-plane 서버(k3s-node-a)와 DB 서버(k3s-node-b) 분리

IaC(Infrastructure as Code) 문서화

고려사항

이러한 과정을 하기 전에 다음과 같은 사항을 고려하였습니다.

기존 네이밍 컨벤션(k3s-node-a)에 맞춰 새 노드를 k3s-node-b로 명명

기존 a,b 노드 라벨링에서 물리적 서버 위치(이하: aws, home이랑 칭함)에 따라 라벨링 변경

node-type = aws : k3s-node-a, k3s-node-b
node-type = home : siwon-server , samlee-server

DB와 contol-plane의 기능을 분리시키기 위해서 DB를 k3s-node-a에서 k3s-node-b로 옮김

Wireguard Host를 k3s-node-a로 지정(Star Topology 유지)

k3s datastore: SQLite 유지

k3s-node-b를 새로 띄워 control-plane을 옮기는 방식으로 다운타임을 줄이고자 했습니다. 그러나 이 경우 datastore를 etcd로 변경해야 하는데, 이처럼 control-plane이 2개가 될 경우 etcd 쿼럼 조건()때문에 서버가 마비될 수 있습니다.

Wiregaurd, k8s 모두 기존 k3s-node-a에서 사용한 고정 IP를 그대로 유지

DB: kubernetes.io/hostname: k3s-node-b / uptime-kuma: kubernetes.io/hostname: siwon-server / redis-pv: no selector

DB와 모니터링 도구는 데이터 보존을 위해 Stateful한 관리가 필요하여 DB는 hostname: k3s-node-b, 모니터링 도구인 uptime-kuma는 hostname: siwon-server으로 설정하였습니다. 반면 Redis는 별도의 노드 종속성을 두지 않아, 임의의 노드에서 해당 노드의 local path를 사용하도록 구성했습니다.

계획

Plan A(Default)

노드 라벨 수정(node-type = a,b → aws,home)

k3s 중지

Postgres, k3s datastore 백업

스냅샷 → large 인스턴스로 k3s-node-backup 생성

xlarge_3_0, ubuntu_24.04 추가 : k3s-node-a large_3_0, ubuntu_24.04 추가 : k3s-node-b

k3s-node-a, b 26.04로 업그레이드

k3s-node-a에 static IP 할당

k3s-node-a에 k3s datastore 넣고 k3s 시작

k3s-node-a를 기준으로 Wireguard 재구성

siwon-server, samlee-server 제대로 붙어 있는지 확인

k3s-node-b cluster로 조인

DB 데이터 디렉토리 이동 후 k3s-node-b에 postgres 생성

Plan B(Second-best)

노드 라벨 수정(node-type=a,b → aws, home)

k3s 중지

Postgres, k3s datastore 백업

스냅샷 → large 인스턴스로 k3s-node-backup 생성

기존 인스턴스 제거 후 k3s-node-backup으로부터 k3s-node-a xlarge_3_0 인스턴스 생성

새로운 인스턴스로 static IP 할당

large_3_0으로 k3s-node-b 생성, cluster에 조인

최대한 빠르게 작업을 끝내기 위해 Plan A 진행 도중 문제가 발생하면 Plan B로 변경할 수 있게 하였습니다.

계획 실행 및 발생한 문제

9월 15일 00:00 경부터 작업을 시작했습니다.

계획대로 노드 라벨 수정, k3s stop, 백업을 진행했습니다.

문제점 1: 노드 스토리지가 130GB를 차지하여 스냅샷 생성이 3~4시간 정도 걸렸습니다. Lightsail은 플랜 업그레이드와 노드 이름 변경이 모두 불가능하기 때문에, 다음과 같은 순서로 노드 이전 및 생성을 진행했습니다.

이후 k3s-node-b 인스턴스를 새롭게 생성하였습니다.

위 과정에서 k3s-node-a, b의 Ubuntu를 26.04로 업데이트했습니다. 작업일(09.15) 기준 Lightsail의 블루프린트는 Ubuntu 24.04까지만 지원하기 때문에, 해당 버전으로 인스턴스를 생성하고 그 뒤에 26.04로 업데이트했습니다.

control-plane인 k3s-node-a부터 세팅을 진행했습니다. 기존에 사용하던 static IP를 할당하고, Wireguard를 설치해 호스트로 지정했습니다.

문제점 2: 세 개의 Worker 노드도 비슷하게 Wireguard를 설정했으나 노드 간 통신이 되지 않았습니다.

편의 상 노드 A, B, C, D로 가정하겠습니다.
wg0.conf에는 Interface(본 노드) 정보와 Peer(타 노드) 정보가 기재되어야 합니다. 즉, B 노드의 conf 파일에는 A, C, D가 Peer로 등록되어야 합니다.
B 노드는 알맞게 설정했으나, C 노드 설정 중 Peer를 A, C, D로 등록했습니다. 자기 자신이 Peer로 들어가도 wg-quick은 문제 없이 성공하지만, B와 연결되지 않았기 때문에 통신이 단절됩니다.
Peer 개수도 3개이고 노드도, Host DNS도 정상적으로 작동하기 때문에 이것을 찾는 데 오랜 시간이 걸렸습니다. Peer를 A, B, D로 등록해 해결했습니다.

Lightsail Console에서 46159 UDP Port를 열지 않아 Wireguard가 작동하지 않는 문제도 있었습니다.

이후 백업한 k3s Datastore를 넣고 k3s를 시작했습니다. k3s-node-b를 cluster에 join하고 postgres를 생성했습니다.

결과 및 회고

개짱짱 클러스터 탄생!

서버 증설 과정에서 기존 인스턴스를 먼저 내린 뒤 새 인스턴스를 세팅했는데, 반대로 새 인스턴스 설정을 미리 끝내놓고 기존 인스턴스를 내렸다면 다운타임을 더 줄일 수 있었을 것 같습니다.